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Verfahren zur Einbinduncr von audiovlsueller codierter 
Information in einen voircreaebenen , 
2ra.hinens trukturi erten ilbertracruncfss tandard sowi e 
Endaerate hierzu 

Stand der Technik 

Fiir die Obertragung von Bild- iind Tondaten niedriger 
Bitraten fur Multimedia Kommunikation wird mittels der ITU- 
H.324 Spezif ikation "Terminal for low bitrate multimedia 
commmunication" ein System spezif iziert , das fur 
Bildtelef onie-Anwendungen geeignet ist. 

Figur 1 zeigt ein Blockschaltbild eines solchen Multimedia 
Systems gemaS dem Standard H.324. In dem mit Bezugszeichen 
1 gekennzeichneten Block sind die Baugruppen, die in H.324 
naher spezif iziert sind, untergebracht . Der Video-Codec 2 
ist gemaB dem Verfahren nach ITU-H. 263/H. 261 ausgebildet. 
Dem Audio-Codec 3 gemaS ITU G.723 ist eine 
Verzogerungseinrichtung 4 nachgeschaltet , urn evtl. 
zeitliche Unterschiede zwischen der Bildcodierung und 
Toncodierung auszugleichen . Die Einrichtung 5 dient zur 
Verarbeitung von Datenprotokollen, z, B. V.14 LAPM usw. , 
und die Einrichtung 6 verarbeitet Steuerprotokolle gemaS 
ITU H.24 5. Den Codecs 2 und 3 werden uber entsprechende Z/O 



A 



- 2 - 



R. 



34251-1 



( Input /Output ) -Einrichtungen 7 und 8 audiovisuelle Daten 
angelief ert . Die Einrichtungen zur Verarbeitung von 
Protokollen 5 und 6 erhalten uber die Einrichtungen 9 (User 
Data Applications) \md 10 (System Control) ihrer 
Eingangsdaten. Die Datenstrome der Codecs 2, 3 sowie der 
Protokollverarbeitungseinrichtungen 5 und 6 werden uber die 
Multiplex- /Demultiplex-Einricht\ing 11 nach dem H.223 
Standard zusammengefuhrt . Das nachgeschaltete Modem 12 
lief ert fur die zusammengef aSten Datenstrome V.3 4 konforme 
Daten und fur die System-Control-Daten V.25 konforme Daten. 
Das Ubertragungsnetz 13 schliefit sich an den Block 1 an mit 
zugehoriger Netzsteuerung 14. 

Vorteile der Erfindung 

Das Verfahren gemaS den Merkmalen des Anspruchs 1 sowie der 
Unteranspruche ist geeignet objektbasiert codierte 
Information, insbesondere nach dem MPEG- 4 
Ubertragungsstandard, in einen vorgegebenen 

rahmenstrukturierten Ubertragungsstandard, insbesondere in 
einen ITU- Standard, einzubinden und ermoglicht so den 
Transport der codierten MPEG- 4 Daten. Gegeniiber 
herkommlichen Video- Codierverfahren, wie dem eingangs 
vorgestellten Videoverf ahren gema£ ITU-H. 263/H. 261 und dem 
Audio-Codec gemaS G. 723.1 ergeben sich insbesondere die 
folgenden Vorteile: 

- objektbasierte Kodierung synthetischer und naturlicher 
visueller Objekte sowie Audio-Ob j ekte , 

- verbesserte Kodieref f izienz , 

- verbesserte visuelle Fehlerrobustheit der Video- 
Kodierung, 

- eigenes Format zur Beschreibung der Anordnung 
audiovisueller Objekte, 

- Synchronisation unterschiedlicher audiovisueller Objekte, 

- Interaktion mit audi ovi sue 11 en Objekten. 
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Dem erf indungsgema£en Verfahren liegen zwei 

unterschiedliche Konzepte - im folgenden als Konzept A und 
B gekennzeichnet - zugrunde. Generell ist jedes der 
Konzepte fur sich allein geeignet die giewunschte 
Funktionalitat - Ubertragung objekt-basiert codierter 
audio-visueller Information - sicherzustellen, jedoch kann 
Konzept A bei groSer Objektanzahl (d.h. einer groSen Anzahl 
von MPEG-4 Datenstromen) vorteilhaft sein. Auch eine 
Kombination der beiden Konzepte ist moglich. 
Das erf indiingsgemaSe Verfahren besitzt daher den groSen 
Vorteil, dag 

alle MPEG-4 Datenstrome - beispielsweise bei Verwendiing 
einer groSen Anzahl von Objekten - mittels der MPEG-4 
FlexMxix-Spezif ikation zu einem Datenstrom paketiert 
werden konnen, der alle Inf ormationen zum Decodieren 
enthalt (Konzept A) , oder bzw. iind 

eine eine bi-direktionale Kommunikation basierend auf den 
gesamten MPEG-4 Funkt ionalitaten durchgefiihrt werden 
kann, ohne da£ aufwendige zusatzliche Anpassiingen der 
MPEG-4 Daten an die Formate des Kommunikationsstandards 
erforderlich waren. Ermoglicht wird dies durch 
konsequente Ausnutzung der von dem 

Multimediakommunikationsstandard H.324 bereitgestellten 
Mechanismen (Konzept B) . 

Weiterhin werden beim Fahigkeiten-Austausch und beim Offnen 
eines Ubertragungskanals die gleichen Datenstrukturen 
verwendet, die den zu ubertragenden Datenstrom-Typen, die 
verwendeten Kodier-Werkzeuge und deren Parameter wie z.B. 
die Datenkapazitat kennzeichnen. 



Durch die Verwendung von Datenpaketen konstanter Lange (Joei 
Konzept A) bzw. die Ausnutzung der Rahmenstruktur des in 
H.324 verankerten Multiplex-Standards H. 223 (bei Konzept B) 
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wird die Fehlerrobustheit erhoht . Die Auf synchronisation in 
den Datenstrom nach einem Fehler ist einfach moglich. 
Eine Kapselung oder auch die Zusammenf uhr\ing 
imterschiedlicher Systeme, z. B. Kombination von H.324 
Plattform imd MPEG-4 Piatt form, ist einfach durchf uhrbar . 

Z e i chnungen 

Anhand der weiteren Zeichnungen wird die Erfindung naher 
erlautert. Es zeigen: 

- Figur 2a und 2b Blockschaltbilder von MPEG-4 Multimedia 
Systemen basierend auf einem H.324 Terminal, 

- Figur 3 den Aufbau eines Flex-Mux Protokolls im Simple 
Mode mit konstanter Lange, 

- Figur 4 den Aufbau eines Flex-Mux Protokolls im Mux Mode 
mit konstanter Lange, 

- Figur 5 einen Adapt ion -Layer Rahmen gemaS ITU H.223, 

- Figur 6 die Verschachtelung der Daten der logischen ITU- 
Kanale, 

- Figur 7 das Header Format , 

- Figur 8 ein Beispiel fur einen Multiplex Entry 
Descriptor, 

- Figur 9 die Einbindung von Paketen konstanter Lange in 
die ITU-Adaption-Layer variabler Lange. 
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Beschreibung von Ausfiihrungsbei spiel en 

Bevor das erf indungsgemaBe Verfahren im Detail beschrieben 
wird; warden zum besseren Verstandnis die verwendeten 
Standards kurz spezif iziert : 

Der Standard ITU-H.324 spezif iziert ein Terminal, welches 
aus einem Video-Codec gemaS H.261/H.263, einem Audio-Codec 
gemaS G. 723, einem Multiplexer gemaS H.223 "und einem 
Kontroll-Protokoll gemafi H.245 besteht. Der Aufbau und das 
Zusammenf iigen der einzelnen Komponenten ist in diesem 
Standard beschrieben. 

Der ITU-H.223 Standard spezif iziert ein paketorientiertes 
Multiplex-Protokoll fur Multimedia-Kommunikation mit 
niedrigen Bitraten. Es wird fur die tJbertragung niedriger 
Bitraten zwischen zwei Multimedia-Terminals oder einem 
Terminal und einer Multi-Point-Einheit eingesetzt. Das 
Protokoll ermoglicht die Ubertragung einer beliebigen 
Kombination von Audio-, Video- und Dateninf ormat ionen uber 
einen einzelnen Kommunikationskanal . Das Protokoll zeichnet 
sich durch "Low-Delay" und niedrigem Overhead aus. Die 
notwendigen Protokoll -Prozeduren zur Imp lementie rung des 
Multiplex-Protokolls werden im H.245 Standard spezif iziert . 

Der Standard ITU-H.245 "Control Protocol for Multimedia 
Communication" spezifiziert die Syntax und Semantik von 
Terminal -Informationen und Nachrichten sowie die Prozeduren 
zum Kommunikationsaufbau. Die Nachrichten ermoglichen den 
Austausch von Terminal-Fahigkeiten/Capabilities , z. B. 
Terminal A signalisiert Terminal B, daS es Video-Daten 
decodieren kann und welche Verfahren es imterstutzt. 

Weiterhin ist ein Protokoll spezifiziert, was die 
zuverlassige Ubertragung von audi ovi sue 11 en Daten mittels 
einer Acknowledge Nachricht erlaubt (Terminal A 
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signalisiert Terminal B den korrekten Empfang des 
Datenpakets) . 

Der Standard ITU-H , 263 /H . 261 Standard spezifiziert die 
Codierung von komprimierten Videodaten fur Kanale niedriger 
Bitraten. 

Der G. 723.1 Standard spezifiziert die Decodierung von 
komprimierten Audiodaten fur Kanale niedriger Bitraten. 

F^r die Ubertragung von MPEG-4 Daten mittels des H.245 
Standards sind folgende Schritte erf orderlich: 

1. Zunachst muS ein Austausch der Fahigkeiten (Capability 
Exchange) der kommunizierenden Terminals stattfinden, urn 
die gegenseitige Kommunikation zu ermoglichen. Die 
Datenubertragung erfolgt in dem dafur vorgesehenen 
logischen Kanal 0 entsprechend H.245. 

2. Des weiteren ist es erf orderlich, die MPEG-4 Dekoder zu 
konf igurieren. Die dazu notwendigen MPEG-4 spezifischen 
Informationen wie der Initial Object Descriptor werden 
entweder mittels H.245 insbesondere dem logischen Kanal 
0 Oder uber einen separaten logischen ITU-Kanal 
ubertragen, insbesondere einem logischen Kanal ungleich 
0 entsprechend dem ITU-H.2 23 Standard. 

3. AnschlieEend mussen mittels des H.245 Standards die 
einzelnen, logischen Kanale zur iJbertragang der 
audi ovi sue 11 en Datenstrome geoffnet werden. 

zu 1.: Austausch der Fahigkeiten (Capability Exchange) 

Fur den Capability Exchange ist es ausreichend, eine MPEG-4 
Capability innerhalb H.245 zu definieren, die wie folgt 
aussehen kann: 
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Isl4496Capability 
{ 

streamType INTEGER (0..255) 

Prof ilelndication INTEGER {0..2S5) 

Levellndication INTEGER (0..255) 

} 

Oder 

Isl44 96Capability 
{ 

StreamType INTEGER (0..255) 

DecoderSpecif icinfo OCTET STRING OPTIONAL 

} 

Oder 

Isl44 96Capability 
{ 

decConf Descr DecoderConf igDescriptor 

} 

Die einzelnen Felder der obigen Datenstrukturen werden in 
den MPEG- 4 Dokumenten (ISO/IEC 144 96) naher erlautert. 
Der Vorteil dieser Capability Definition begrundet sich in 
dem geringen Daten-Overhead und einem Verweis auf die 
Spezif ikation innerhalb des MPEG-4 Standards und damit die 
Vermeidung eines Overheads an zusatzlichen Definitionen im 
H, 24 5- Standard, Der streamType definiert den Typen (d.tL. 
den Inhalt) des Datenstroms, der Profile Indikator 
definiert die Dekodier-Werkzeuge und der Level die 
Parameter dieser Dekodierwerkzeuge . Innerhalb MPEG-4 sind 
unter anderem diese Parameter enthalten mit Ausnahme der 
Level Indication, die noch zu spezif izieren ist von MPEG. 

Die isl4496Capability dient auch dazu, bei Konzept B 
mittels des „Data Type" Feldes beim Offnen eines logischen 
Kanals mit der H.245 Funktion OpenLogicalChannel den in 
diesem Kanal ubertragenen MPEG-4 Daten-Typen anzuzeigen. 
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zu 2 . : Konf iguration der Dekoder 

Nachdem mittels des Capability Exchange die 

Terminalf ahigkeiten definiert sind, wird die Konf iguration 
der Dekoder durch die Ubertragiing der Initial Object 
Descriptoren bzw, der Object Descriptoren durchgef uhrt . 
Dieses geschieht entweder mittels eines request /confirm 
Kommandos nach H.24 5, innerhalb dessen die Initial Object 
Descriptoren ausgetauscht werden oder durch das Offnen 
eines neuen logischen ITU-Kanals, der nur den Initial 
Object Descriptor oder den SL-packetierten Object 
Descriptor Strom enthalt. 

zu 3 . : Offnen der logischen Kanale und Dateniibertragung 

Nach der Konf iguration werden die einzelnen ITU-Kanale 
geoffnet. Allgemein gilt: 

Die audiovisuellen kodierten Informationen, . insbesondere 
gemafi MPEG-4, werden zu separaten Datenstromen aufbereitet . 
Ein Encoder, der einen MPEG-4 konformen Datenstom 
generiert, liefert an seinem Ausgang bereits mehrere dieser 
separaten Datenstrome, insbesondere SL (Synchronisation 
Layer) -paketierte Datenstrome. In Figur 2a und Figur 2b 
sind die Elementardatenstrome (El. Streams) am "Elementar-y 
Stream Interface" der Sync (Synchronisation) -Layer 
dargestellt. Hierbei ist zu beachten, dafi der Header der 
SL-Pakete auch zu „NULL" konfiguriert - also weggelassen - 
werden kann. Innerhalb dieses "Sync Layer" erfolgt die 
Paketieriang der Elementardatenstrome, die dann am "Stream 
Multiplex Interface" fur die Weiterverarbeitung abgreifbar 
sind. 



GemaS Konzept B geschieht das Offnen eines logischen Kanals 
mit der in H.245 definierten OpenLogicalChannel Message. 
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Das „portNumber'' -Feld dient beim Offnen des jeweiligen 
logischen Kanals zur Signalisierung der zugeordneten 
Elementardatenstrom-Identif ikation {ES_ID) , mittels derer 
die Datenstrome MPEG-4 -seitig referenziert werden. Mit dem 
^streamType^' -Feld, dem hier der Wert einer 
Isl4496Capability zugewiesen wird (es konnen also die 
gleichen Datenstrukturen wie beim Cpability Exchange 
verwendet werden) , wird dabei jeweils explizit der Inhalt 
eines logischen Kanals (d.h. der MPEG-4-Objekttyp) 
angegeben. Bei der eigent lichen - dann folgenden - 
Datenubertragimg wird bei Konzept B jeder einzelne SL- 
paketierte MPEG-4 Datenstrom am „ Stream Multiplex 
Interface" abgegriffen und in einem logischen ITU-Kanal 
ubertragen. Die SL-paketierten iyiPEG-4 Datenstrome werden 
hierzu vom H.223 Adaptat ionLayer als AL-SDU Pakete 
weiterverarbeitet und mittels des H.223 Standards 
gemultiplext {Ausf uhrungsbeispiel gemaS Fig. 2a) . Diese 
Ubernahme des MPEG-4 Framing der Daten in ein Framing gema£ 
H-223 (SL-PDU := AL-SDU) erhoht die Fehlerrobustheit und 
erlaubt eine einfache Resynchronisation, falls ein Pakets 
fehlerhaft ubertragen wurde. Zudem wird hierdurch eine 
ansonsten zusatzlich notwendige Adaption des MPEG-4 
Datenformats an das Format des Multiplexers 'vermieden. 
Das Konzept B ermoglicht das (spatere) dynamische 
Hinzufugen weiterer MPEG-4 Datenstroms. 

Fur die Umsetzung von Konzept A werden die einzelnen 
Datenstrome zu insgesamt nur einem Datenstrom mittels des 
MPEG-4 FlexMux gemultiplext und in insgesamt einem 
logischen ITU-Kanal ubertragen (Ausf uhrungsbeispiel gemaS 
Fig. 2b) . Fur diese Art der Ubertragung von MPEG-4 
Datenstromen mittels des FlexMux werden zusatzliche 
Descriptoren definiert, die den Verbindungsaufbau 
ermoglichen. Nur mit diesen ist die Erkennung der einzelnen 
MPEG-4 Datenstrome moglich. Diese MPEG-4 -spezifischen 
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Datenstrome werden mittels des MPEG-4 Flexmux Tools 
gemultiplext . Hierbei wird die Verwendung von Paketen 
konstanter Lange definiert, wodurch die Fehlerrobustheit 
erhoht wird. Die Auf synchronisation in den Datenstrom nach 
einem Fehler ist so moglich. 

Nachfolgend wird das Konzept A im Detail beschrieben. 

Wie Figur 2b zeigt, konnen folgende logischen MPEG-4- 
Objekte (SL-paketierte Datenstrome) mittels des MPEG-4 
FlexMux-Tools in einen Ubertragungsrahmen gemultiplext xxnd 
in einem logischen ITU-Kanal ALl ubertragen werden: 
SL- Audio, 
SL- Video, 

SL-OCR (Object Clock Reference) , 

SL-OD (Object Descriptor) , 

SL-OCI (Object Content Information) . 

In einer leichten Abwandlung von Konzept A ist es auch 
moglich, Daten des ausschliefilich gleichen Typs (also z.B. 
entweder nur SL-Audio oder nur SL-Video) in einen logischen 
Kanal mit Hilfe des FlexMux-Tools zu multiplexen, d.h. die 
Gesamtheit der MPEG-4 -Datenstrome wiederum in mehreren 
(allerdings wenigeren als bei Konzept B) logischen ITU- 
Kanalen zu ubertragen. Dieses wurde u.U. eine einfachere 
Trennung \ind Dekodierung der gemultiplexten Daten im 
Empf anger ermoglichen. Im folgenden wird jedoch wiederum 
das ursprungliche Konzept A, also das Multiplexing aller 
MPEG -Datenstrome in einen logischen ITU-Kanal mittels des 
FlexMux-Tools betrachtet . 

Das Konzept A ermoglicht (ebenso wie Konzept B) die 
Ubertragung mehrerer MPEG-4 -Datenstrome des gleichen Typs, 
wie z.B. die Ubertracpung mehrerer Audiostrome fur einen 
bild-begleitenden Ton in unterschiedlichen Sprachen . 
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Fur das Verfahren gemaS Konzept A ist es notwendig, 
MUXCODETABLE_Entry wahrend der Initialisieriingsphase zu 
iibertragen, um den MPEG- 4 FlexMux zu konf igurieren . 

Letztendlich muiS dem MPEG-4 Dekoder die vorgenommene 
Zuordnung der einzelnen ES-Strome zu den zu multiplexenden 
Daten mitgeteilt werden. Dies wird mittels einer Channel 
Map Table (oder auch Stream Map Table genannt) erreicht. 

Diese beiden Inf ormationen sind neben den Objekt 
Deskriptoren fur die Dekodierung notwendig. 

Um die zusatzlichen Inf ormationen MUXCODETABLE_Entry und 
Channel Map Table in den Initial Object Descriptor 
einzufugen, ist die Definition neuer Descriptoren 
notwendig, Diese werden in Form von Extension Descriptors 
in den Initial Object Descriptor eingefugt . 

Class Channel Map Table Descriptor: bit (8) tag= to be 
defined 



bit (16) length: 

Bit (15) streamCount; 

Bit (1) MultiplexCodeFlag; 

For (i=0; i< streamCount; i++^ 



Bit (16) ES_ID; 

Bit (8) FlexMuxChannel; 

IFMultiplexCodeFlag^ 



Bit (4) MultiplexCode; 
Bit (4) reserved; 
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Der f ettgedruckte Tail zeigt den hier neu definierten 
Descriptor. 

Ahnlich kann auch der Aufbau eines 
MuxCodeTableEntryDesccriptors erf olgen : 

Class MuxCodeTableEntryDescriptors : bit (8) tag= to be 
defined 



bit (16) length; 

bit (4) niimber Of MoixCodeTableEntries ; 

bit (1) constantLengthFlag; 

bit (3) reserved; 

IF constantliengthFlag 

bit (8) FlexMiixLength; 
For {j=0; j<nTiinberOfMuxCodeTableEntries; j ++^ 

bit (8) length; 

bit (4) MuxCode; 

bit (4) version; 

bi t ( 8 ) subs t ructureCoimt ; 

for (i=0; i<substructureCount ; i++) ( 



bit (5) slotCount; 

bi t ( 3 ) repet it ionCount ; 

for(k=0; k<slotCo\mt ; k++) ( 

bit(8) f lexMuxChannel (i) (k) ; 

bit (8) numberOf Bytes (i) (k) ; 



Der f ettgedruckte Teil zeigt den hier neu definierten 
Descriptor. Das Datenfeld numberOf MuxCodeTableEntries 
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ermoglicht die Ubertragimg der maximal 16 

MuxCodeTableEntries . Mittels des constantLengthFlag und dem 
Feld FlexMuxLenth wird dem Empf anger signalisiert , daS die 
FlexMiix-Pakete mit konstanter Lange mit der PaketgroSe 
FlexMuxLenth + 2 ubertragen werden. 

Die in MPEG- 4 definierten FlexMux-Pakete werden zum einen 
in dem Simple Mode gemaS Fig. 3 und zum anderen in dem 
MuxCode gemaS Fig. 4 ubertragen. 

Durch Verwendung von Paketen konstanter, ungerader Lange, 
hier 127 Bytes, konnen die oberen 7 Bits des Length Felds 
zur Synchronisation genutzt werden. 

Dieses erhoht die Fehlerrobustheit und erlaubt eine 
Resynchronisation, falls ein Langenfeld eines Pakets 
fehlerhaft ist. 

Diese FlexMux - Pakete mussen nun in einen ITU-Rahmen 
eingebunden werden. In Figur 5 ist ein Adaptation Layer 
(AL) -Rahmen gemafi ITU-H,223 gezeigt, mit einem AL-PDU 
(Protocol Data Unit) Payload Field. Aufgrund der variablen 
Lange eines FlexMux Pakets ware das Auffinden eines neuen 
FlexMux Pakets nach einem Fehler im Langenfeld nicht mehr 
moglich. Dieses ist besonders schadlich, wenn mehrere MPEG- 
4 Elementarstrome (z. B. BIFS, OD, und Video) in einem ITU 
Kanal ubertragen werden. 

Durch Verwendimg konstanter Langen innerhalb der MPEG-4 
FlexMux Pakete, nach der Erfindiing, ist dies nun wiederum 
moglich. 

Die einzelnen AL-PDU Pakete variabler Lange werden nun 
mittels des Multiplexers verpackt . 

Der Aufbau des Multiplex Layer und die prinzipielle 
Einbindung des MPEG-4 FlexMux Datenstroms wird kurz 
erlautert . 
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Eine MUX Protocol Data Unit (MUX-PDU) besteht aus einem 
Header und einem Information Field, indem die Daten der 
einzelnen logischen ITU Kanale verschachtelt sind. Figur 6 
zeigt den Aufbau. 

Der Header besteht aus einzelnen Feldern, die in Figur 1 
gezeigt sind. 

Der 4 Bit groSe Multiplex Code zeigt auf einen uber H.245 
ubertragenen MultiplexEntry, wovon maximal 15 verschiedene 
definiert werden konnen. 

Das Header Error Control Feld ist ein 3 Bit grofies CRC 
Feld, welches eine Fehler-Erkennung im Header zulaEt . 

Das 1-Bit Packet Marker Feld markiert das Ende einer MUX- 
SDU eines segmetierten logischen Kanals. 

Das in Figur S gezeigte Inf ormations-Feld wird mittels der 
in H.245 ubertragenen MultiplexTable konf iguriert . 

Das Inf ormations-Feld kann mit einem Closing Flag jederzeit 
an einer Oktett-Grenze abgeschlossen werden, jedoch darf 
eine MUX-SDU von einem nicht segment ierbaren Kanal nicht 
\mterbrochen werden. 

Der MultiplexEntryDescriptor konf iguriert den H.223 
Multiplexer und wird in der Initialisierungsphase 
ubertragen (Figur 8) . 



In dieser Figur bedeutet LCN: LogicalChannelNumber , RC: 

RepeatCount , UCF :UntilClosingFlag. 

Der Vorteil wird in der Figur 9 deutlich: 
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wenn in einem ITU-Kanal mehrere MPEG-Daten ubertragen 
warden und MPEG- 4 Pakete variabler Lange benutzt warden, 
dann sind alia folgenden FlexMiixPakete nicht mehr 
decodierbar. Die gaschickte Verwendiing das Langanfalds als 
ain Synchronisationsmarker erlaiibt die Auf synchronisation 
des Empf angers . 

Das sendende Tenninal signalisiert dem empfangendan 
Terminal die Paketlange mittels des hier definiarten 
MuxCodeTableEntryDescriptors, der durch ain Flag 
gekennzeichnet ist, welches die Verwendiing von FlexMiix 
Paketan konstanter Lange signalisiert und waiterhin ein 
Feld enthalt, welches die zu verwandenda Lange festlegt. 
Hierdurch ist eina groSe Flexibilitat varbiinden mit einar 
groSan Fehlerrobustheit gawahrlaistet . 

Die Erfindung kann naturlich nicht nur fur MPEG-4 Daten 
verwendat warden, sondern auch fur andere audiovisuelle 
codierta Information, die in einen standardisierten 
Ubertragungsrahmen einzubinden ist und deren Dekodierung 
einfach und fehlerrobust erfolgan soli. 

Das vorgestellte Verfahren kann naturlich in senderseitigen 
und empf angsseitigan Endgaraten realisiart warden. Fur die 
sandersaitiga Einbindimg miissan antsprechende Mittal zur 
Aufbereitung bzw. zur Anlieferung von audiovisualler 
codierter Information vorgesehen sein sowie antsprechende 
Mittal zum Multiplexen der Datenstrome, zum Austausch der* 
Fahigkeiten und zur Signal isierung . Fur die empf angsseitige 
Auswartung sind Mittal zur Zerlegiing der gemultiplexten 
Datenkanala sowie Mittal zum Austausch der Fahigkeiten und 
deren Auswertung und zur Auswertung der Signalisierung 
notwendig. Da ublicherweise im Dialogverkehr gearbeitet 
wird, sind Teilnehmerendgerata sowohl fiir den Sende- als 
auch fur den Empf angsbetrieb ausgerustet. 
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Anspruche 

1. Verfahren zur Einbindiing von audiovisueller codierter 
Information in einen vorgegebenen rahmens trukturierten 
Ubertragungsstandard mit folgenden Schritten: 

die audiovisuelle codierte Information wird zu separaten 
Datenstromen aufbereitet, bzw. wird in Form von separaten 
Datenstromen angeliefert, 

die einzelnen Datenstrome werden in einen bzw. mehrere 
Datenkanal/- kanale des rahmens trukturierten 
Ubertragungs standards gemultiplext , 
die Fahigkeiten, insbesondere die Codier- und 
Decodierf ahigkeiten, der miteinander kommunizierenden 
Endgerate werden nach dem Aufbau einer Verbindung 
ausgetauscht , 

zur Signalisierung werden Datenstrukturen eines 
Kodierstandards verwendet, die Angaben uber den 
verwendeten Datentyp, das zu benutzende Decodierwerkzeug 
land die Kodierungsparameter wie z.B. die Datenkapazitat 
enthalten. 

2. Verfahren nach Anspruch 1, dadurch giekennzeichnet , daS 
die Datenstrukturen, die beim Austausch der Fahigkeiten land 
beim Offnen eines Ubertragiingskanals verwendet werden, 
gleich gewahlt sind. 

3. Verfahren nach Anspruch 1 oder 2, dadurch 
gekennzeichnet , dafi beispielsweise fur objektbasierte 
audiovisuell codierte Information mit geringer Objektanzahl 
die entsprechenden Datenstrome mittels eines Multiplexers, 
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insbesondere eines Multiplexers nach dem H.223 Standard, 
paketiert warden iind in einzelnen Ubertragungskanalen, 
insbesondere ITU-Kanalen entsprechend dem H.245 Standard, 
xibertragen werden. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet , daS 
zur Zuordnung der einzelnen Pakete innerhalb der ihnen 
zugeordneten Ubertragungskanalen, ein Datenfeld 
(„portNumber" - Feld) dient, das bei einer MPEG-4 
Ubertragung eine Identif ikation der einzelnen Elementar- 
Datenstrome (ES-ID) enthalt. 

5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daS 
von dem Multiplex- Verfahren das Datenformat der MPEG-4 - 
Ausgangsdatenstrome (SL-PDUs) direkt iibernommen wird, so 
daS keine weitere Umf ormatierung notwendig wird. 

6. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daS 
Objektdescriptoren, insbesondere der „ Initial Object 
Descriptor'^ nach MPEG-4, fur audiovisuelle codierte 

Inf ormationen in einem separaten Kanal, insbesondere einem 
logischen Kanal -ungleich 0 entsprechend dem ITU- H.223 
Standard, untergebracht werden. 

7. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daS 
fur objektbasierte audiovisuell codierte Information - 
beispielsweise bei groSer Objektanzahl - die entsprechenden 
Datenstrome zu einem gemeinsamen Datenstrom gemultiplext 
werden und in einem Ubertrag\ingskanal , insbesondere in 
einem ITU- Kanal, ubertragen werden. 

8. Verfahren nach einem der Anspruche 1, 2 oder 7, dadurch 
gekennzeichnet, daS neben den gemultiplexten Datenstromen 
im trbertragungsrahmen des rahmenstrukturierten 
Ubertragungs standards eine Signal isierungs inf ormat ion 
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untergebracht wird, die darauf hinweist, daS gemult iplexte 
Inf ormationspakete konstanter Lange ubertragen warden, 
aufgrimd derer eine Synchronisation, insbesondere bei 
fehlerhaften Datenpaketen, duchfuhrbar ist. 

9. Verfahren nach einem der Anspruch 1, 2 oder 7, dadurch 
gekennzeichnet , dafi Obj ektdescriptoren, insbesondere der 

„ Initial Object Descriptor nach MPEG-4, fur audiovisuelle 
codierte Inf ormationen in einem zusatzlichen Kanal , 
insbesondere dem logischen Kanal 0 entsprechend dem ITU- 
H.245 Standard, untergebracht werden. 

10. Verfahren nach einem der Anspruche 1, 2, 7 oder 8, 
dadurch gekennzeichnet , dafi Zuordnungsdaten zwischen den 
separaten Datenstromen, insbesondere SL paketierten MPEG-4 
Elementardatenstromen und den gemultiplexten Daten in dem 
zusatzlichen Kanal, insbesondere dem logischen Kanal 0 
entsprechend dem ITU- H.24 5 Standard, untergebracht werden. 

11. Verfahren nach einem der Anspruche 1, 2, 7, 8 oder 9, 
dadurch gekennzeichnet, daS fur die 

Signalisierungsinf ormation Datenfelder vorgesehen werden, 
welche zum einen die konstante Lange und die PaketgroSe der 
gemultiplexten Inf ormationspakete kennzeichnen. 

12. Verfahren nach einem der Anspruche 1, 2, oder 7-10, 
dadurch gekennzeichnet, da£ als audiovisuelle codierte 
Information MPEG-4 Daten verwendet werden, die zu Flex-Mux- 
Paketen konstanter Lange aufbereitet werden, und dalS diese 
Flex-Mux-Pakete konstanter Lange in einen 
Ubertragungsrahmen gemultiplext werden, die eine 
Ubertragung gemaS dem ITU-Standard H.324 ermoglicht. 

13. Verfahren nach einem der Anspruche 1 bis 12, dadurch 
gekennzeichnet, daS innerhalb der „ Adaptation Layer" 
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variabler Lange gema£ ITU-Standard H.324 mehrere MPEG-4 
Daten in Datenpaketen konstanter Lange imtergebracht 
warden, wobei im Anf angsbereich dieser Datenpakete jeweils 
ein Langenfeld vorgesehen ist, welches als 
Synchronisationskennung , insbesondere zur 
Auf synchronisation eines Empf angers, verwendbar ist. 

14. Endgerat zur senderseit igen Einbindung von 

audi ovi sue ller codierter Information in einen vorgegebenen 
rahmenstrukturierten Ubertragungs standard mit folgenden 
Merkmalen: 

Mitteln zur Aufbereitung der audiovisuellen codierten 
Information zu separaten Datenstromen an das Endgerat 
bzw. zur Anlieferung in Form von separaten Datenstromen 
an das Endgerat, 

Mitteln zum Multiplexen der einzelnen Datenstrome in 
einen bzw. mehrere Datenkanal/- kanale des 
rahmenstrukturierten tibertragungsstandards , 
Mitteln zum Austausch der Fahigkeiten, insbesondere der 
Codier- und Decodierf ahigkeiten, mit weiteren Endgeraten 
insbesondere nach dem Aufbau einer Verbindung, 
Mitteln zur Signalisierung imter Verwendung von 
Datenstrukturen, die Angaben liber den verwendeten 
Datentyp, das zu benutzende Decodierwerkzeug und die 
Kodierungsparameter wie z.B die Datenkapazitat enthalten. 

15 . Endgerat zur empf angsseitigen Auswertung von 
audiovisueller codierter Information in einem vorgegebenen 
rahmenstrukturierten Ubertragungs standard mit folgenden 
Merkmalen : 

Mitteln zur Zerlegung eines bzw. mehrerer gemultiplexter 
rahmenstrukturierter Datenkanale eines 
Ubertragungsstandards in einzelne audiovisuelle 
Datenstrome, 




Mitteln zum Austausch der Fahigkeiten, insbesondere der 
Codier- und Decodierf ahigkeiten, mit weiteren Endgeraten 
insbesondere nach dem Aufbau einer Verbindung, 
Mitteln zur Signalisierung iinter Verwendung von 
Datenstrukturen, die Angaben uber den verwendeten 
Datentyp, das zu benutzende Decodierwerkzeug xand die 
Datenkapazitat enthalten . 
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Verfsihren znr Einbinduncr von audiovisueller codiert^r 
Information in elnen vorcfecrebenen. 
rahmenstruk turi eirten Ubertracruncrs s tanda.rd sowi e 
Endaerate hierzu 

Zu s ammen £ a s s ung 

Zur Einbindung von audiovisueller codierter Inf oirmation in 
einen vorgegebenen , rahmenstrukturierten 

Ubertragimgs standard warden einzelne Datenstrome in einen 
bzw. mehrere Datenkanal/- kanale des rahmenstrukturierten 
Ubertragungsstandards gemultiplext . Ausserdem werden die 
Fahigkeiten der kommunizierenden Endgerate asgetauscht. 



(Figur 2a) 
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